from 128GB to 256GB

from 128GB to 256GB

* Disable peers banning

* Increase max LMDB size (#3120)

from 128GB to 256GB

* This is a series of patches to reduce bandwidth consumption from a large amount of frontiers.

* Broadcasting blocks only when an election is started rather than immediately upon receipt.

* more changes regarding github actions security hardening (#3088)

https://docs.github.com/en/actions/learn-github-actions/security-hardening-for-github-actions#using-third-party-actions

Co-authored-by: Russel <russel@nano.org>

* Remove recently dropped check to restart elections

Up until "recently", a new write transaction was opened to update work on the ledger for every single block. Now with deferred work updates on the block processor, it is no more expensive than processing a new block, so it makes sense to remove this constraint of having been recently dropped. This improves quality of service.

The previously implicit check for confirmed dependents (since the election was dropped) is now explicit. The work on the ledger is updated regardless of that check passing.

The election is not immediately inserted as *active* anymore, same behavior as the normal election insertion path.

Note that if an election is active, the work is **not** updated on the ledger. That behavior also seems desirable. This could be achieved by updating the store after the block is identified as old, directly within `ledger::process`. For post-processing, a flag can be passed to `blockprocessor::process_old`, at which point `active_transactions::restart` can be scrapped since it becomes a simple election insertion + stats update (with a dependents confirmed check). Since this change would touch ledger code I am leaving for others to do it. There's also the question if the confirmed status should be checked within the ledger processing code.

Note: only tested via core_test.

# Conflicts:
#	nano/core_test/active_transactions.cpp
#	nano/core_test/node.cpp
#	nano/lib/locks.cpp
#	nano/lib/locks.hpp
#	nano/node/active_transactions.cpp
#	nano/node/active_transactions.hpp

* Show frontiers age in RPC

* This decreases the confirm_req_batches_max from 20 to 2, equivalent to 280/sec -> 28/sec. This option is also made configurable.

Confirm_req batches are used in the bootstrap process and excessive requests to reps can degrade performance and often get dropped.

# Conflicts:
#	nano/node/active_transactions.cpp
#	nano/node/confirmation_solicitor.cpp
#	nano/node/nodeconfig.cpp
#	nano/node/nodeconfig.hpp

* This removes bootstrap restarting code as it is ineffective and can cause unnecessary restarting of the bootstrap process.

* Bumping version number.

* Including missing header.

* Optionally send confirmed frontiers with an optional flag.

* Throttled removal of rep crawler targets (#3154)

* Throttled removal of rep crawler targets

* Remove recursion

Co-authored-by: Russel Waters <russel@nano.org>
Co-authored-by: Sergey Kroshnin <sergiysw@gmail.com>